Amiga Plus 1995 #2/Amiga Plus CD - 1995 - No. 2.iso/internet/faq/englisch/computer-security-compromise

Text File | 1995-04-11 | 14.3 KB | 312 lines

Archive-name: computer-security/compromise-faq
Posting-frequency: monthly
Last-modified: 1995/01/02
Version: 2.0

Compromise FAQ

Version: 2.0
    ------------------------------------------------------------------------

This Security FAQ is a resource provided by:

     Internet Security Systems, Inc.
     2000 Miller Court West            Tel: [phone]
     Norcross, Georgia  30071          Fax: [phone]

     - Computer Security Consulting - Penetration Analysis of Networks -

    ------------------------------------------------------------------------

To get the newest updates of Security files check the following services:

     mail [e-mail] with "send index" in message
     http://iss.net/~iss
     ftp iss.net /pub/

    ------------------------------------------------------------------------


What if your Machines are Compromised by an Intruder.

This FAQ deals with some suggestions for securing your Unix machine after it
has already been compromised. Even if your machines have not been compromised,
there are many helpful tips on securing a machine in this paper.

  1.  Try to trace/follow the intruder back to his origin via looking at

       1.  who
       2.  w
       3.  last
       4.  lastcomm
       5.  netstat
       6.  snmpnetstat
       7.  router information.
       8.  /var/adm/messages (many crackers send e-mail to their "home"
          accounts)
       9.  syslog (sends logs to other hosts as well)
      10.  wrapper logs
      11.  do a 'finger' to all local users(and check where they last logged in
          from)
      12.  history files from shells, such as .history, .rchist, and similiar
          files.

     Footnote: 'who', 'w', 'last', and 'lastcomm' are commands that rely on
     /var/adm/pacct, /usr/adm/wtmp, and /etc/utmp to report the information to
     you. Most backdoors will keep the intruder from being shown in these logs.
     Even if the intruder has not installed any backdoors yet, it is trivial to
     remove any detection in these logs. But they may just forget about one or
     two of them. Especially if you have some additional, non-standard ones.

     Suggestion: Install xinetd or tcp_wrapper that will log all connections to
     your machine to see if someone is knocking on its doors. Forward syslogs
     to another machine so intruder will not easily detect the logs and modify.
     Other possibilities: netlog from net.tamu.edu:/pub/security.

     It might be wise to monitor the intruder via some ethernet sniffer to see
     how he is exploiting his systems before taking corrective measures.

  2.  Close the machine from outside access. Remove from network to stop
     further access via intruder. If the intruder finds out that the
     administrator is unto him, he may try to hide his tracks by rm -rf /.

  3.  Check the binaries with the originals. Especially check the following
     binaries because they are commonly replaced backdoors for regaining
     access:

       1.  /bin/login
       2.  all the /usr/etc/in.* files (ie. in.telnetd)
       3.  and /lib/libc.so.* (on Suns).
       4.  anything called from inetd

     Other commonly replaced backdoor binaries:

       1.  netstat - allows hiding connections
       2.  ps - allows hiding processes (ie Crack)
       3.  ls - allows hiding directories
       4.  ifconfig - hides the fact that promiscuity mode is on the ethernet
       5.  sum - fools the checksum for binaries, not necessarily replaced
          anymore because its possible to change the checksum of the binaries
          to the correct value without modifying sum. *EMPHASIZE* Do NOT Rely
          on sum.

     Use 'ls -lac' to find the real modification time of files. Check /etc/wtmp
     (if you still have one) for any system time adjustments. Check the files
     with the distribution media (CD or tape) or calculate MD5 checksums and
     compare them with the originals kept offline (you did calculate them
     sometime ago, didn't you?) Suggestion: cmp the files with copies that are
     known to be good.

     Another popular backdoor is suid'ing a common command (ie. /bin/time) to
     allow root access with regular accounts.

     To find all suid programs you may use:

          find / -type f -perm -4000 -ls

     To be thorough you may need to re-load the entire OS to make sure there
     are no backdoors. Tripwire helps prevent modifying binaries and system
     files (ie. inetd.conf) on the system, without the administrator knowing.

  4.  Implement some password scheme for your users to verify that they change
     their passwords often. Install anlpasswd, npasswd, or passwd+ in place of
     passwd (or yppasswd) so that your users are forced to set reasonable
     passwords. Then run Crack, which is available on
     ftp.cert.org:/pub/tools/crack to make sure that your users aren't
     bypassing the password check. Crack ensures that users are picking
     difficult passwords. With the network, clear text passwords are a problem.
     Other possible choices: smart hubs (stops ethernet sniffing of the whole
     LAN) and one-time password technology.

  5.  Check all the users' .rhosts and .forward files to make sure none of them
     are weird or out of the ordinary. If .rhosts file contains '+ +', the
     account can be accessed anywhere by anyone without a password. COPS has a
     scripts for checking .rhosts.

          find / -name .rhosts -ls -o -name .forward -ls

     Look also for all the files created/modified in the time you are
     suspecting the break-in has taken place, eg:

          find / -ctime -2 -ctime +1 -ls

     To find all the files modified not less than one day ago, but not more
     than 2.

     All .login, .logout, .profile, .cshrc files are also worth looking at (at
     least for the modification date/time). Make sure there are no '.rhosts'
     for the locked or special accounts (like 'news', 'sundiag', 'sync', etc.)
     The shell for such accounts should be something like '/bin/false' anyway
     (and not '/bin/sh') to make them more secure. Also search for directories
     that have like ". ", ".. " as names. They are usually found in /tmp ,
     /var/tmp, /usr/spool/* and any other publicly writeable directory.

  6.  Check to make sure your NFS exports are not world writable to everyone.
     NFSwatch available on harbor.ecn.purdue.edu:/pub/davy , a program by David
     Curry, will log any NFS transactions that are taking place. Try 'showmount
     -e' to see whether system agrees with your opinion of what are you
     exporting and where. There are bugs in some nfsd implementations which
     ignore the access lists when they exceed some limit (256 bytes). Check
     also what are you IMPORTING!!! Use 'nosuid' flag whenever possible. You do
     not want to be cracked by a sysadm from another host (or a cracker there)
     running suid programs mounted via NFS, do you?

  7.  Make sure you have implemented the newest sendmail daemon. Old sendmail
     daemons allowed remote execution of commands on any Unix machine. See the
     computer-security/security-patch FAQ.

  8.  Try to install all the security patches available from the vendor on your
     machine. See the computer-security/security-patch FAQ.

  9.  Here is a check list of common ways that a machine is vulnerable:

       1.  Do an rpcinfo -p on your machine to make sure it is not running any
          processes that are not needed. (ie. rexd).

       2.  Check for '+' in /etc/hosts.equiv.

       3.  Check whether tftp is disabled on your system. If not - disable it,
          or at least use '-s' flag to chroot it to some safe area, if you
          really can't live without it (it is mostly used for booting up
          Xterminals, but sometimes can be avoided by NFS-mounting appropriate
          disks). Under no circumstances you should run it as root. Change the
          line describing it in /etc/inetd.conf to something like:

               tftp dgram udp wait nobody /usr/etc/in.tftpd in.tftpd -s
               /tftpboot

          or better yet, use tcpd wrapper program to protect it from addresses
          which should not get access to tftp and log all other connections:

               tftp dgram udp wait nobody /usr/etc/tcpd in.tftpd -s
               /tftpboot

          and edit appropriately /etc/hosts.allow to restrict access to
          in.tftpd to only those addresses that really need it.

       4.  Check crontabs and at-jobs. Make sure there are no delayed bombs
          which will explode after you think you have got rid of all the nasty
          things left by a intruder.

       5.  Check /etc/rc.boot /etc/rc.local (SYSV: /etc/rc?.d/* ) and other
          files cruicial for the system startup. (The best would be if you
          could compare them with the copies kept off-line). Check all other
          files containing system configuration (sendmail.cf, sendmail.fc,
          hosts.allow, at.allow, at.deny, cron.allow, hosts, hosts.lpd, etc.)
          In 'aliases' look for aliases expanding to some unusual programs
          (uudecode is one but example).

       6.  Check your inetd.conf and /etc/services files to find if there are
          no additional services set up by an intruder.

       7.  Copy all the log files you still have (pacct, wtmp, lastlog, sulog,
          syslog, authlog, any additional logs you have set up earlier) to some
          safe place (offline) so you may examine them later. Otherwise, do not
          be surprised if they disappear the next day when the cracker realises
          he forgot to remove one of them. Use your own imagination to find
          what other traces he could have left in your system (What about
          /tmp/* files? Check them BEFORE you reboot).

       8.  Make backup copy of /etc/passwd (best offline) then change all root
          passwords (after verifying that 'su' and 'passwd' are not the trojan
          versions left by an intruder). It may sound like a horrible thing to
          do (especially if you have something like 2000 users) but *do* lock
          them all by putting '*' in the password field. If the intruder has a
          copy of your passwords file he may possibly sooner or later guess all
          the passwords contained there (It is all the matter of proper
          dictionaries). In fact he could have inserted few passwords that he
          only knows for some users who for example have not logged in for a
          long time.

          On the NIS servers check not only the real /etc/passwd /etc/groups
          etc files but also those used for building NIS maps (if they are
          different).

       9.  Check if your anonymous ftp (and other services) are configured
          properly (if you have any of course) See the
          computer-security/anonymous-ftp FAQ.

      10.  If you want to make your life easier next time (or if you still
          cannot get rid of an intruder) consider installing 'ident' daemon.
          Together with tcpd on a set of hosts it can be used to find what
          accounts the intruder is using.

      11.  Make sure the only 'secure' terminal is console (if at all). This
          way you prevent root logins just from the net. Maybe it is not a big
          deal as if somebody knows the root password he may already know other
          peoples' passwords too, but maybe not?

      12.  Check hosts.equiv, .rhosts, and hosts.lpd for having # as comments
          within those files. If an intruder changes his hostname to #, it will
          be considered a trusted host and allow him to access your machines.

      13.  And remember... There are so many ways that somebody could have
          modified your system, that you really have to have your eyes and ears
          wide open for a loooooong long time. Above, are the pointers just to
          the most obvious things to check.

 10.  Mail all the sites that you were able to find out that the intruder was
     going through and warn them. Also, CC: [e-mail]. Check all the sites
     in your near-by, ie. in your domain/institution/whatever. It's usually
     trivial for a hacker to get to another system by a simple 'rlogin' if the
     two systems have a common subset of users (and using .rhosts to make the
     access easier).

 11.  A preventive from stopping many intruders from even trying your network
     is to install a firewall.

     Side-effects: Firewalls may be expensive; filtering may slow down the
     network. Consider blocking nfs (port 2049/udp) and portmap(111/udp) on
     your router. The authentication and access controls of these protocols is
     often minimal. Suggestion: Block all udp ports except DNS and NTP ports.
     Kill all source routing packets. Kill all ip-forwarding packets.

Acknowledgements

Thanks to the following people for adding and shaping this FAQ:

Tomasz Surmacz <[e-mail]>
Wes Morgan ([e-mail])
Alan Hannan ([e-mail])
Peter Van Epp <[e-mail]>
Richard Jones <[e-mail]>
Wieste Venema <[e-mail]>
Adrian Rodriguez <[e-mail]>
Jill Bowyer <[e-mail]>
Andy Mell <[e-mail]>

    ------------------------------------------------------------------------


Copyright

This paper is Copyright (c) 1994, 1995
   by Christopher Klaus of Internet Security Systems, Inc.

Permission is hereby granted to give away free copies electronically. You may
distribute, transfer, or spread this paper electronically. You may not pretend
that you wrote it. This copyright notice must be maintained in any copy made.
If you wish to reprint the whole or any part of this paper in any other medium
excluding electronic medium, please ask the author for permission.

Disclaimer

The information within this paper may change without notice. Use of this
information constitutes acceptance for use in an AS IS condition. There are NO
warranties with regard to this information. In no event shall the author be
liable for any damages whatsoever arising out of or in connection with the use
or spread of this information. Any use of this information is at the user's own
risk.

Address of Author

Please send suggestions, updates, and comments to:
Christopher Klaus <[e-mail]> of Internet Security Systems, Inc.
<[e-mail]>


--
Christopher William Klaus       Voice: [phone]. Fax: [phone]
Internet Security Systems, Inc.         Computer Security Consulting
2000 Miller Court West, Norcross, GA 30071